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REMARKS 

The Office Action of October 15, 2008 has been reviewed in detail and this paper is 
responsive thereto. Claims 12-28 are pending. Claims 12-19 and 24, and 26 stand rejected. 

Applicant acknowledges that claims 20-23, 25, 27, and 28 are objected to by the 
Examiner as being dependent upon a rejected base claim, but would be allowable if rewritten in 
independent form including all of the limitations of the base claim and any intervening claims. 

No new matter has been introduced into the application. As explained in more detail 
below. Applicants respectfully submit that all remaining pending claims are in condition for 
allowance. 

Claim Rejections Under 35 USC §103 

Claims 12-15, 18 and 24 are rejected under 35 USC §103(a) as being unpatentable 
over US Publication No. 2003/0026201 (Arnesen) in view of US Patent No. 6,587,500 
(Persson). 

Regarding independent claim 12, Arnesen and Persson, either individually or in 
combination, fails to suggest the features of "starting data extraction from the bit stream when 
the correlation value exceeds a threshold value to indicate that a data packet has been detected" 
and "restarting data extraction from the bit stream when the new correlation value exceeds the 
stored maximum correlation value." The Examiner's argumentation regarding the features of 
pending claim 12, which define "starting data extraction from the bit stream to indicate that a 
data packet has been detected" and "restarting data extraction from the bit stream", should be 
considered. On page 2 of the Office Action, the Examiner argues that feature of independent 
claim 12, which reads "starting data extraction from the bit stream to indicate that a data packet 
has been detected", would be anticipated by Arnesen, which would describe "start packet 
extraction command 1202 and 1203; [0132, a correlation process]". On page 3 of the Office 
Action, the Examiner further argues that feature of independent claim 12, which reads "restarting 
data extraction from the bit stream", would be also anticipated by Arnesen, which would 
describe "restarting packet extraction after correlation process; 1203". Hence, the Examiner 
identifies the operation "starting data extraction..." and "restarting data extraction..." with the 
very same process of Arnesen, which describes that packet-start output, i.e. the start-of-packet 



-6- 



Response dated 01/09/2009 

Reply to Office Action of 10/15/2008 



Application No. 09/981,795 



command, of the packet-header detector 1202 is provided to the symbol detector 1203 (cf. 
paragraph [0129] and [0132]). Thereby, the Examiner ignores that the terms "starting" and 
"restarting" refer to different processes in the context of the description of the present 
application. 

As defined in the subject matter of claim 12, the data extraction is started [. . .] to indicate 
that a data packet has been identified. The starting condition is hence the identification of a data 
packet, which is controlled by the determination of a correlation value for detecting the data 
packet. Insofar, the feature of "starting data extraction..." might be considered as being 
comparable to Amesen, which describes (as aforementioned) that the packet-header detector 
1202 detects a packet preamble for instance using a correlation process that outputs a correlation 
value as the preamble vector p^. In order to show that the "restarting data extraction..." as 
defined in the subject matter of claim 12 must not be interpreted as "starting data extraction. . . of 
a new data packet", the Examiner arguments on page 3 of the Office Action with regard to the 
feature of independent claim 12, which reads "continuing comparing the bit stream with the 
expected bit sequence", should be considered. The Examiner interprets the feature "continuing 
comparing. . ." in that that "the process is repeated for each packet extraction " (cf : "it is inherent 
[to Amesen] that the process is repeated for each packet extraction ; 1202"). 

In contrast to Amesen, the subject matter of claim 12 does not define a repetitive data 
extraction for each next data packet , the subject matter of claim 12 defines a "continuing 
comparing the bit stream with the expected bit sequence to determine a new correlation value". 
In the context of the subject matter of claim 12, which firstly defines "comparing a bit stream 
derived from a received digital data stream with an expected bit sequence to determine a 
correlation value for detecting a data packet" it is in our view immediately appreciated that 
"continuing comparing the bit stream with the expected bit sequence..." refers back to the 
"starting data extraction ... to indicate that a data packet has been detected". This means that 
"continuing comparing the bit stream with the expected bit sequence..." is preformed during 
data extraction. Amesen only suggests that the packet-header detector 1202 detects a packet 
preamble while symbol extraction is not performed. During symbol extraction, the packet-header 
detector 1202 is not operated to detect a packet preamble. The packet-header detector 1202 is set 
into operation again upon reception of the end-of-packet output from the frame module/packet 
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framer 1204. In further context of the subject matter of claim 12, it is immediately understood as 
well that the "restarting data extraction from the bit stream when the new correlation value 
exceeds the stored maximum correlation value" is performed during an already started data 
extraction process once a new correlation value exceeds the stored maximum correlation value 
because the new correlation value is obtained during an already started data by "continuing 
comparing the bit stream with the expected bit sequence to determine a new correlation value". 

Therefore, Amesen and Persson, either individually or in combination, fail to suggest the 
features of "continuing comparing the bit stream with the expected bit sequence to determine a 
new correlation value" and "restarting data extraction from the bit stream when the new 
correlation value exceeds the stored maximum correlation value". 

For the sake of completeness, it should be mentioned that the description, on the basis of 
which the terms of the claimed subject matter has to be interpreted, also supports unambiguously 
the aforementioned understanding of the subject matter of pending claim 12. For instance, in 
paragraph [0039] on page 3 of the publication (US 2003/0076905 Al of the present apphcation): 

"The packet detector 17 is responsible for indicating the presence of valid 
packets. The packet detector 17 gets the demodulated and filtered waveform 
signal DW as input and provides a correlation value CorrVal as output signal. 
The correlation value CorrVal indicates the degree of similarity between the bit 
sequence of the received waveform and an expected bit sequence." 

Further, in paragraph [0057] to [0059] on pages 3 and 4 of the publication, it is described that 

"[0057] By entering the state SEARCH PACKET the packet detector 17 [... is] 
enabled. The packet detector 17 delivers a correlation value CorrVal to the sync- 
control module 23 which indicates the degree of similarity between a bit stream of 
a received demodulated waveform and the expected access code or 
synchronization word. When CorrVal exceeds a programmable threshold 
CorrThres the wanted packet is supposed to be found. In this case the state 
PACKET FOUND is entered in case that the signal Sync Win is high or 1 . 
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[0058] Always when the state PACKET FOUND is entered the latest correlation 
value CorrVal is stored in a register MaxCorrVal of the sync-control module 23 
(not shown). 

[0059] Whenever a new correlation value CorrVal from the packet detector 17 
exceeds the registered correlation value MaxCorrVal, while at the same time the 
state FINISHED has not been reached [i.e. while for instance SEARCH TIMING 
state, SYNC-FOUND state or ACTIVE state], while the signal Sync Win is high 
or 1 the state PACKET FOUND is reentered and MaxCorrVal is set to the new 
value. I. e., the synchronization process can be restarted in the state PACKET 
FOUND. As a consequence the synchronization unit can continue with scanning 
for access codes while data extraction is already prepared or even started . In case 
the correlation value CorrVal indicates a higher level of confidence (higher 
correlation value CorrVal) compared to the last packet detection, the 
synchronization process is restarted. So far extracted data is rejected . Restarting 
of the synchronization process may be called multiple sync-found." 

[0060] An advantage of multiple sync-founds is that the tradeoff between the false 
alarm rate and the packet detection performance under noisy conditions is eased, 
as always the best matching sequence can be detected . [...]" 

Finally, it could be considered the teaching of Amesen as modified by Perrson as 
suggested by the Examiner would result in a feasible solution. For this purpose, the Examiner's 
allegations should be assumed, i.e. that "starting data extraction" would correspond to the start- 
of-packet command sent by the packet-header detector 1202 to the symbol detector 1203 and 
"restarting data extraction" would correspond to the same start-of-packet command sent by the 
packet-header detector 1202 to the symbol detector 1203, when a subsequent next data packet is 
detected (see end of page 2 and top of page 3 of the Office Action). The Examiner has further 
assumed that the correlation process is repeated for each packet extraction; 1202 (see top of page 
3 of the Office Action). Now, the updating of the comparator threshold value as allegedly 
suggested by Persson should be combined with the aforementioned teaching of Amesen. This 
means that the packet-header detector 1202 using a correlation process starts outputs a 
correlation value and detects a first data packet if the outputted correlation value equals or 
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exceeds a predefined correlation threshold value. This predefined correlation threshold is stored 
after successful detection. When the subsequent next data packet is to be detected by the packet- 
header detector 1202, the stored correlation threshold is retrieved and the detection is successful 
if the packet-header detector 1202 using the correlation process outputs a new correlation value, 
which equals or exceeds the stored correlation threshold. If the outputted new correlation value is 
stored replacing the currently stored correlation threshold. This process is repeated with each 
next data packet. This means that the correlation threshold maintains the same value or increases 
but the correlation threshold never decreases. If now by chance the packet-header detector 1202 
outputs a (substantially) maximum correlation value, which is then stored as the next correlation 
threshold, a next data packet will not be detectable any more in the bit stream due to the 
maximum correlation threshold. 

Independent claim 18 includes the similar feature of "a sync-control circuit configured to 
receive the correlation value from the packet detector, the sync-control circuit configured to 
control the data extraction unit for starting or restarting data extraction from the bit stream when 
the correlation value exceeds a threshold value or a stored maximum correlation value indicating 
that a data packet has been detected, and configured to store the correlation value that exceeds 
the threshold value as a maximum correlation value for use as a new threshold value." Also, 
independent claim 24 includes the feature of "a sync-control circuit configured to receive the 
correlation value from the packet detector, the sync-control circuit configured to control the data 
extraction unit for starting or restarting data extraction from the bit stream when the correlation 
value exceeds a threshold value or a stored maximum correlation value indicating that a data 
packet has been detected, and configured to store the correlation value that exceeds the threshold 
value as a maximum correlation value for use as a new threshold value." Thus, claims 18 and 24 
are patentable for at least the above reasons. Moreover, claims 13-15 ultimately depend from 
claim 12. Applicant requests reconsideration of claims 12-15, 18 and 24. 

Further, it should be noted that with reference to claim 14, which depends from claim 12, 
the Examiner asserts that 

"Persson et al discloses wherein the correlation value is stored as the maximum 
correlation value each time data extraction is started or restarted and the new 
correlation value continuously determined after starting or restarting data 
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extraction is compared with the stored maximum correlation value (Fig. 4, L40- 
53)." 

In this context, the question arises, when should the threshold be updated, if the threshold value 
is always overwritten with the correlation value independent whether the correlation value 
exceeds the threshold value or not. From the above explanation; it is immediately apparent that 
the subject matter of independent claim 12 does not result to the aforementioned situation This 
is because, the features "storing the correlation value that exceeds the threshold value as a 
maximum correlation value for use as a new threshold value"; "continuing comparing the bit 
stream with the expected bit sequence to determine a new correlation value"; and "restarting data 
extraction from the bit stream when the new correlation value exceeds the stored maximum 
correlation value" define processes, which are performed during an already started data 
extraction. The subject matter of dependent claim 14 further defines that in order to detect a 
subsequent next data packet, the threshold value, which has to be exceeded by the correlation 
value such that the data extraction is started is reset. 

Moreover, claim 15, which depends from claim 12, also includes the feature of ''wherein 
data extracted prior to restarting data extraction is rejected". The Office Action alleges on page 
4 that: 

Regarding claim 15, Persson et al. disclose wherein data extracted prior to 
restarting data extraction is rejected (since Persson teaches updating threshold 
value to reduce the probability of false alarm (Col 3, L21-25), it is obvious that 
the data extracted from the previous threshold (i.e., false alarm) should be 
rejected so as to improve quality (official notice is taken here)). 

The Examiner merely repeats the formerly presented allegation without responding to the 
arguments presented in the previous reply. In addition to the previously presented arguments 
against the Examiner's allegation, it can be argued additionally that the "restarting data 
extraction. . ." does reduce the probability of false alarm as argued by the Examiner with respect 
to Persson et al. Rather, the subject matter of the pending claim 12 and in particular the subject 
matter of claim 15 depending on claim 12 defines that a false alarm is accepted in that the ''data 
extraction from the bit stream is started once the correlation value exceeds a threshold value to 



-11- 



Response dated 01/09/2009 

Reply to Office Action of 10/15/2008 



Application No. 09/981,795 



indicate that a data packet has been detected'. But a false alarm is detected during already 
started data extraction ''when the new correlation value, which is determined by continuing 
comparing the bit stream with the expected bit sequence during the already stared data 
extraction, exceeds the stored maximum correlation value". Then ''data extraction from the bit 
stream is restarted" and in particular, "the data extracted prior to restarting data extraction is 
rejected". Persson et al. tries to reduce the probability of false alarm before any determination of 
optimum sampling timing (sampling phase). Hence, Persson fails to suggest the rejection of any 
extracted data. 

Claims 16, 17, 19, and 26 are rejected under 35 USC §103(a) as being unpatentable 
over Arnesen in view of Persson and in further view of US Patent No. 5,619,542 (Gurney). 

Claims 16, 17, 19, and 26 ultimately depend from claims 12, 18, and 24. Moreover, 
Gumey merely describes methods and devices for predicting a symbol timing estimation in a 
digital radio receiver and fails to remedy the deficiencies of Arnesen and Persson. (Column 1 , 
lines 42-44.) Applicant thus requests reconsideration of claims 16, 17, 19, and 26. 

Applicants therefore respectfully request reconsideration of the pending claims and a 
finding of their allowability. A notice to this effect is respectfully requested. Please feel free to 
contact the undersigned should any questions arise with respect to this case that may be 
addressed by telephone. 

Respectfully submitted. 

Dated: January 9, 2009 Bv: /Kenneth F. Smolik/ 

Kenneth F. Smolik 
Registration No. 44,344 
BANNER & WITCOFF, LTD. 
10 South Wacker Drive, Suite 3000 
Chicago, IL 60606 
Telephone: 312-463-5000 
Facsimile: 312-463-5001 
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